Hello, there has been an illness running around the office this week, so productivity has been down. Regardless, it is still friday, so here are the Factorio Facts.
Hello, version 0.15.30 was released today, and we consider it to be our first 0.15 stable version candidate, as long as no other big bugs appear, we will have 0.15 stable in a week. As the teasing never ends, it is time to show some ongoing work on 0.16 already.
Hello guys, past week has prepared some ups and downs for us. On the up side, we have marked the 0.10.12 as stable and we also moved closer to getting the multiplayer reasonably working. On the down side our reservation for the new office has been cancelled which means we had to start looking for an office place yet again. That is rather unfortunate because we really liked the place we picked originally. Anyway, I am sure we will find another one soonish (we have already had couple of viewings this week but so far without success).
Status report (Twinsen) On Monday June 18th, we marked the last version of 0.16 as stable. There were no major problems, so now we are almost exclusively working on 0.17. Work on 0.17 is progressing well: Regarding the new campaign, we are already internally playing a rough version of the new player experience. We are still trying to figure out the exact and final style and concepts for the improved GUI, but we have some GUI windows implemented in game already, plus many base widgets. We use those to get a feel of what works and what doesn't. The new graphics back-end rewrite is nearing finalization. A closed-beta branch was sent to a few players to test that rendering works correctly across different hardware. The rendering is faster and no major issues were reported so far. But there is still much to do, such as improvements to VRAM usage and many experiments with shaders. Since from the graphics department Albert is working on the GUI and V453000 is working on the new campaign, only Ernestas is left working exclusively on the entity graphics. He is reworking some more entities for high-resolution, so expect some teasers in the future. There are of course other small projects that are ongoing, such as improved pipe-fluid physics and improved map generation, but more on those when they are fleshed out. Oh, and our coding always goes as planned without any problems.
Hi folks, so this has been one of those weeks when it is suddenly Friday afternoon and you are wondering where did the week go. Fortunately there are the Friday Facts to put myself together and retrace the events=)) The Grey Zone At the moment we are kind of in a grey zone. The 0.12 bugs are more or less solved (though there is still some "popping up" of new issues) and the full speed work on 0.13 hasn't started yet (actually not even slow speed work has started). We are finishing with little (often technical debt) tasks from our internal lists. There is just ton of issues like: fixing locale fonts, updating tips and tricks, writing tests for compilcated existing functionality, tweaking our automatic deployment and testing setup, auto-generating the Lua API documentation, fixing sound glitches, etc. The list goes on. One of the tasks has been related to our headless binary. This is the binary to run on linux servers without graphics card. This is now available in the downloads section alongside other releases. There is a small convenience difference where by clicking the download, the resulting download link (from one of our cdn servers) is valid for 10 minutes (instead of regular 10 seconds) so the server owner can conveniently copy this url and download the game directly from the server. In the future we plan to have the updater work for headless servers as well so that will make things even more convenient. The good news is that the list of these little tasks is getting shorter. Also we have already more or less agreed on distribution of big tasks for the 0.13. These have been discussed in the past and are also visible at our roadmap. Some work on these should start already next week. We will keep you up to date=)
Bugfixing report (posila) Stabilization goes well, the game seems to be quite stable right now (as in - not many crashes are being reported), in fact I think we are at the phase where additional bugfixing makes the game less stable, because more bugs are introduced than fixed, or some critical bug slips through our automated tests. But there are still lot of issues that need to be resolved before we declare 0.16 stable and move on to 0.17 development - the largest issue being belt compression problems. We finally fixed compatibility problem with OS X 10.9 Mavericks after it was broken in 0.15.40, when we updated our development environment to a newer version of boost, and was still broken in 0.16.x despite of us completely replacing boost with standard libraries from a newer version of C++. However, we might drop Mavericks support in 0.17, as we are considering migrating the game to OpenGL 4.1, which won’t be available on Macs that are unable to run a newer version of macOS. Speaking of OpenGL, we have several reports of the game crashing in rendering on Linux when the game is disturbed somehow (for example window resizes, loses focus or user switches workspaces), even though it is terribly inconvenient, the game seems to be otherwise playable on these configurations, and we don’t want to spend a terrible amount of time trying to figure out what is wrong with our current rendering system, when we plan to do complete overhaul of it in 0.17. We will investigate these issues, but they might go unresolved until 0.17. I’ve been looking into some corrupted saves this week, still not being able to figure out how these mysterious corruptions occur. For example this save had two iron ore entities on two different chunks saved with zero entity ID. This could have happened only if those entities had a wrong pointer to the iron ore prototype, so when the game read the ID from the prototype on saving, it would read a value from some random part of memory, or if the ID was corrupted on copying from the prototype to buffer that is saved to disk. Since these kind of corruptions seem to be relatively rare, we suspect it might caused by random hardware failures (maybe cosmic ray hitting a transistor and flipping bit somewhere?), but it would be nice to have some proof it is not some dangling pointer in our code that causes random parts of memory to be overwritten by who knows what. One way to test it would be to check for tile corruptions. Tile data for a chunk is allocated in a 4kB array at the beginning of the chunk. We could create custom allocator for chunks, so that data structure representing chunk is aligned to virtual pages. That way tile data would occupy a whole single virtual page which we could flag as read only. Then, if due to a bug we write over tile data, the OS would crash the game and we would get a stacktrace and crash dump to investigate. But if a cosmic ray would hit the RAM and flip a bit, the corrupted save would still be produced. However, we currently don’t do any custom allocation of virtual pages, so it might be quite hard to implement. We also need to change tiles sometimes (when map generation runs, when player uses concrete or landfill, when a script changes tiles, etc.) and we don’t know how expensive it would be to change pages from read only to read-write and then back to read only. So it might be just easier to spend two hours on fixing a broken save that someone sends us once every week or two.
This week's Friday Facts is brought to you by Robert aka Twinsen aka that Romanian dude aka the Combinator guy. I'll be talking about the improvements that have been done so far in 0.13 to the circuit network.
Tomorrow's party Since a couple of weeks ago I was working for the 1M Party. Made some little graphic design jobs which finally became not that little and much more than "some little". I have to admit that I had quite some fun doing them, cause these small things are giving me the chance to experiment and play with the graphical identity of Factorio, like the happy logo variation, the small jumping gear, some layouts, the 1 color version of the Factorio logo and so on. Luckily I finished the jobs with time enough as to come back to the game gfx. But to be honest, Jitka is the person who's really taking care of every single detail for the party, and preparing and organizing everything. She became a master with the stamp and other stuff that I can't reveal just to not spoil surprises.
